PLDs are a well-known type of integrated circuit that may be programmed to perform specified logic functions. One type of PLD, the Field Programmable Gate Array (FPGA), typically includes an array of programmable tiles. These programmable tiles can include, for example, Input/Output Blocks (IOBs), Configurable Logic Blocks (CLBs), dedicated Random Access Memory Blocks (BRAM), multipliers, Digital Signal Processing blocks (DSPs), processors, digital clock managers (DCMs), Delay Lock Loops (DLLs), Multi-Gigabit Transceivers (MGTs) and so forth.
Each programmable tile typically includes both programmable interconnect and programmable logic. The programmable interconnect typically includes a large number of interconnect lines of varying lengths interconnected by Programmable Interconnect Points (PIPs). The programmable logic implements the logic of a user design using programmable elements that may include, for example, function generators, registers, arithmetic logic, and so forth.
The programmable interconnect and the programmable logic are typically programmed by loading a stream of configuration data into internal configuration memory cells that define how the programmable elements are configured. The configuration data may be read from memory (e.g., from an external PROM) or written into the FPGA by an external device. The collective states of the individual memory cells then determine the function of the FPGA.
Another type of PLD is the Complex Programmable Logic Device, or CPLD. A CPLD includes two or more “function blocks” connected together and to input/output (I/O) resources by an interconnect switch matrix. Each function block of the CPLD includes a two-level AND/OR structure similar to those used in Programmable Logic Arrays (PLAs) and Programmable Array Logic (PAL) devices. In CPLDs, configuration data is typically stored on-chip in non-volatile memory. In some CPLDs, configuration data is stored on-chip in non-volatile memory, then downloaded to volatile memory as part of an initial configuration (programming) sequence.
For all of these PLDs, the functionality of the device is controlled by configuration data bits provided to the device for that purpose. The configuration data bits can be stored in volatile memory (e.g., static memory cells, as in FPGAs and some CPLDs), in non-volatile memory (e.g., FLASH memory, as in some CPLDs), or in any other type of memory cell.
Some PLDs, such as the Xilinx Virtex® FPGA, can be programmed to incorporate blocks with pre-designed functionalities, i.e., “cores”. A core can include a predetermined set of configuration data bits that program the FPGA to perform one or more functions. Alternatively, a core can include source code or schematics that describe the logic and connectivity of a design. Typical cores can provide, but are not limited to, DSP functions, memories, storage elements, and math functions. Some cores include an optimally floor planned layout targeted to a specific family of FPGAs. Cores can also be parameterizable, i.e., allowing the user to enter parameters to activate or change certain core functionality.
Verification of the configuration data that is used to configure the FPGA into a particular design is often required, so as to obviate the possibility of a flawed design configuration due to a corrupted configuration bitstream. Thus, a procedure known as readback verify is provided, whereby during a configuration event, a configuration bitstream may be downloaded into a configuration memory space through a configuration controller that is configured for write mode. Next, the downloaded configuration bitstream may be verified by configuring the configuration controller for read mode, whereby the contents of the configuration memory space are obtained through the same configuration interface that was used during the configuration event. The configuration data obtained through readback verify may then be compared to the original configuration data to determine whether any bit errors occurred during the configuration event.
Additionally, verification of the functionality of a design may also be required to determine whether a particular user design meets certain design criteria. As such, a procedure known as readback capture may be used as a superset of readback verify, whereby in addition to the configuration data contained within the configuration memory space, the current state data of all CLB and IOB registers may also be obtained. Thus, readback capture is a procedure that is valuable during design debugging operations, for example, whereby a portion of the current state data of a particular user design may be decoded to determine whether the user design is functioning as anticipated.
Readback verify and readback capture, however, are each controlled by the configuration controller, which imposes global restrictions on the functionality and subsequent usability of the readback verify and capture procedures. In particular, IOB/CLB flip-flop state data may be requested via the configuration controller, but the flip-flop state data of the entire FPGA is returned by such a request.
If readback capture is not required or permitted from certain portions within the FPGA, then those portions are “masked” by the design software. In one example, the logic content of certain primitive logic resources, such as look-up table RAM (LUTRAM) resources, is destroyed by the execution of a read cycle on the corresponding configuration data frame. As such, the design software prohibits readback capture of LUTRAM resources within the FPGA, so as to avoid destruction of the LUTRAM logic content. For all other logic resources contained within the FPGA, the design software determines whether to discard, ignore, or mask the configuration data.
Additionally, while conventional readback capture procedures allow for the readback of certain logic resources, such as BRAM resources, the BRAM resources cannot be accessed by the user logic during the readback capture procedure. Thus, readback capture functionality of the BRAM resources is somewhat inhibited.
Efforts continue, therefore, to provide greater flexibility for readback capture procedures, so as to allow independently controlled readback capture of user defined regions. Further, previously inhibited logic resources should be made available for readback capture so as to increase effectiveness during debugging sessions.